The Atari Compendium

home *** CD-ROM | disk | FTP | other *** search

/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / umich / telecomm / stadel / stadel2.zoo / document / manager.doc < prev next >

Wrap

Text File | 1989-08-11 | 18.1 KB | 461 lines

Things that a Sysop should know about running STadel 1) SYSOP FUNCTIONS INSIDE CITADEL STadel can be thought of as having 3 levels to it: the Peon level (normal users), the Aide level (people with special privileges), and the Sysop level. They are differentiated, of course, by what they can do to a STadel system. What normal users can do is decided by the Sysop's policy decisions in CTDLCNFG.SYS. Aides have 4 commands available to them that is not available to the normal users. These are accessed thru the command ".Aide <cmd>", and they are: ------------------------------- [D]elete empty rooms [E]dit current room [I]nsert pulled message [K]ill current room ------------------------------- These are detailed in AIDE.HLP. Details on how to make a normal user into an aide and vice versa are below. Aide functions may be used from either a remote location or from the system console. The Sysop(s)' functions differ from the Aide functions in that they may be used ONLY from the System Console, and in that the Sysop does NOT have to be logged in if s/he does not wish to be to perform these special functions. In fact, somebody else can be logged in. To perform Sysop functions, first ensure that STadel is in CONSOLE mode. If you are in MODEM mode, hit the ESC. If somebody is on from remote, interrupt him/her only at the room prompts. Once in CONSOLE mode, push a CTRL L (control key and L key simultaneously); STadel should then print 'privileged cmd: ' or somesuch. You now have access to Sysop special functions. With the exception of [S]et date below, none of these are accessible to the Aides or anyone else. ------------------------------- [B]aud selection. [C]hat toggle. [D]- Toggle debug mode. [E]- Toggle screen echo. [F]ile grab. [I]nformation. [K]ill account. [M]ODEM mode. [N]etwork commands. [O]utside commands. [P]- Toggle aide privileges. [Q]uit citadel. [R]einitialize Modem. [S]et date. [T]elephone call. e[X]it sysop menu. [Y]- Show time til next event. [Z]- Autodial. ------------------------------- [A]bort or e[X]it are one (of 3) way out of the Sysop command menu. Abort puts you back into -CONSOLE- mode. The [C]hat switch is a toggle switch that will either tell users that you are not around, or will ring the Console's bell to call you. The [D]ebug switch is for use when debugging STadel. It's of no use for normal STadel installations. To destroy a person's account on a STadel system, use the [K]ill Account command. You will be asked for a name; if STadel finds a user by that name, then it'll ask for confirmation. [M]odem mode is the second way to exit the Sysop command menu. It leaves STadel in -MODEM- mode. The [P]rivilege switch is how you assign and take away Aide privileges from people. STadel, when this option is selected, will ask for a name. If it finds who you specify, it will print out what toggling this person's aide switch will do, and then ask you to confirm if that's what you want to do with that person. [S]et date allows you to set the date and time. This data will be used to set the system clock. The [T]elephone command is a way to use STadel as a modem program -- it will ask you for a system name and if it finds that system name on your network list it will call it and drop into Chat mode. [Q]uit is the 3rd and last way to exit the Sysop cmd menu. This folds STadel up and returns you to the operating system. [Z] puts you into a autodialer. When you type [Z], STadel will ask you for a list of systems to call (terminated with a blank line) and then the number of times to redial each system. After this, it will loop through the list of systems until you type any key to abort the callout or until it connects with one. If it connects with one, it will beep at you and drop into chat mode. 2) ARCHIVING ROOMS An interest has been expressed recently in giving Citadel the ability to automatically maintain, in some way, a record of conversations that are held. This has been motivated by the CitaBook project, story-telling, and other subjects that have, for one reason or another, given the system operator reason to pause, think, and wish to save those messages in a far more permanent form than as a Citadel message, which will inevitably scroll. Therefore, Citadel now has the ability to maintain just such a textfile on disk. Called (for the time being) the Archive feature, it allows the sysop to designate virtually any room to be an Archive room. Such a room then will have a filename associated with it. Within the file of that name, each and every message that is entered into that room will also be appended to a archive file. 2.1) PROCEDURE The procedure to designate a room as Archive is to simply edit the room (note that this automatically excludes Aide>, Mail>, and the baseRoom as Archive rooms). One of the questions that you will encounter will concern Archive status of the room. If you answer yes, the system will do one of two things: A) If the room was not an Archive room before, it'll ask for a filename to associate with the room. B) If it was already an Archive room, it'll just assume that the filename should remain the same, and not bother you further about Archive stuff. If it does ask for filename, the filename that you should type in can be located anywhere in the system that you desire. Once you have typed it in, Citadel will attempt to archive all the messages that are currently in the room (message numbers will be spewed out at this point to reassure you that there is* method in Citadel's madness). An Archive room puts each new message into the Archive file when it is initially entered into the room (note that Aide actions, such as deleting the message later, does not affect the Archive file). 2.2) CONSIDERATIONS This feature is recommended only for high-performance systems, particularly those with fairly fast hard disks, since each message is, in effect, saved twice. Furthermore, since active rooms will result in very fast file growth, close tabs should be kept on disk free space by the sysop. 2.3) NOTES This is all Torkildson's fault. The filenames are stored in the new .SYS file CTDLARCH.SYS file. This file is unique in the respect that it is a human readable text file. Each Archive room on the system will have an entry in this file, in the following format: <room#><space><full-filespec> Thus, if the sysop wants to modify what file to store the Archive data in without going through the hassle of editing the room twice (see above), s/he can whip out their handy-dandy text editor, and fix it right then and there. 3) ARCHIVING MAIL The sysop may archive his mail to disk by using the #archive-mail command in ctdlcnfg.sys. If you set #archive-mail "person", all mail to and from "person" will be archived to the file sysop.msg in your #auditdir. 4) FILE DESCRIPTIONS (FILE TAGS) File tagging is the ability to associate a short text description with a file, which can be displayed on command, along with the file names. STadel will now support two different ways to display the contents of a directory room's directory. The first is the old way, and will remain the same -- .R(ead) D(irectory). The second method is used to display the file descriptions, and is .R(ead) <E(xtended directory). The format of a directory listing using .RE is like this: fn1 f1size | f1 description (date created) fn2 f2size | f2 description (date created) . . . fnx fxsize | fx description (date created) The fnX is filename x, and fXsize is the size of that file in xmodem sectors. The output is, of course, formatted to the users screen, so people with screens <= 40 are going find these listings a little hard to follow... So, how do we put these descriptions in, you ask? (I should let you folk guess!) For each directory room that you want to have descriptions for the files, there must be a file named `$DIR' (`.DIR' on the Atari ST.) Within this file will be the descriptions, formatted in the following way: fn1<tab>f1 description fn2<tab>f2 description . . . fnX<tab>fX description Each fnX is the filename, in the left most column of the screen. "fX description" is the description for that file. It is limited to one* line for each file. However, that line may extend up to 7000 characters, so if you have a text editor that will handle 7000 characters on one line, and really want to do that to your users... Between each fnX and its description there must be at least* one tab. Each filename must be in uppercase, and the filenames must be in alphabetical order for .RE to work properly. STadel puts new file descriptions into the $DIR file in the proper order when somebody uploads a file to the system. 5) OPERATING HINTS Citadel systems haven't had great reliability problems to date, but reasonably regular backups aren't a bad idea anyhow. An incremental archive program is contemplated. Message files can be expanded via use of EXPAND.TOS; see UTIL.DOC. Still, it's a good idea to start with a big system and not screw around with it too much. There's nothing compiled into the system concerning the number or structure of .HLP files. The system just looks for a ".HLP" file with the requested name, and prints it. Feel free to edit existing help files and add new ones as typical points of confusion become clear. Helpfiles may also be put in directory rooms, of course. A local-BBs listing probably makes more sense as a .HLP file; segmenting the local-BBs help file into several files is another thought if there are a large number of local BBSs. If you want mail to Sysop to go to your account, there is a variable in ctdlcnfg.sys that you can set to send it there - #sysop "person" will send all sysop mail to person. On Pell, it is set up as #sysop "orc" to send all sysop mail to me. 5.1) Pointlets o The system does a 20-sec wait on bad passwords, to discourage password guessing. If you're establishing a new account, use a single-letter pw on first password prompt, and you can bypass this. o The system converts messages from uppercase-only folks to lowercase, then does a simple capitalization algorithm. This is lots easier on the eyes, but will confuse someone sooner or later. o There are also several utilities for use with the system. See UTIL.DOC. o There are several options you can give STadel on the command line to vary its behavior; `+hup' will leave the phone active when you exit STadel and when you ESC to console mode, `+netlog' will keep a log of all network activities in the file NETLOG.SYS in your audit directory, `+netdebug' turns network debugging on, `+ymodem' will make the default extended networking protocol ymodem (the normal default is wxmodem), and `+line' (on ST's only) puts a status line at the bottom of the screen. 6) WHERE THE VARIOUS STADEL FILES GO #sysdir CTDLLOG.SYS CTDLROOM.SYS CTDLDOOR.SYS CTDLFLR.SYS CTDLARCH.SYS #msgdir CTDLMSG.SYS #netdir CTDLNET.SYS ALIAS.SYS UUCP.INI UUCP.SYS <Network workfiles> #helpdir <All the help, menu, and blurb files> #auditdir CHAT.REC CALLLOG.SYS NETLOG.SYS FILELOG.SYS SYSOP.MSG #receiptdir <All files gotten from the network> #mirrordir CTDLMSG.SYS (backup) 7) CITADEL IN A SHELLSCRIPT No program is ever bug-free. However, it is nice to pretend that one is, and an effective way to pretend that a particular program has achieved such a goal is by never having it require your attention when you are attending to other things. STadel tries to emulate this sort of software by returning a value to the operating system when it terminates gracefully. There are 3 possible values returned by STadel that can be read by a batch file (provided, of course, that you are using a batch processor that can handle it): 0) indicates that the sysop requested that the program terminate. 2) indicates ABNORMAL termination, i.e., the system had an error of some sort and has crashed gracefully. 3) indicates that a Remote sysop has taken the system down via Remote sysop capabilities. Furthermore, STadel, when called with ANY argument(s) on the command line, will leave message in the Aide> room notifying the aides that the system came up at the time specified in the message header. The argument itself doesn't matter; it's presence on the command line is the important part. And, plus, when Configur is called with any argument(s) (just like Citadel, above), it will assume that it is in unattended mode, and will not ask the sysop if he wants to erase the files; it will assume that since the sysop is not around, he wants to preserve his data files, and just scans the files. What can you do with the above? Here is the batch file I use for running STadel with the teeny-shell (my own shell....) > # > # Fire pell up and let it fly... > # > here=$cwd > cd f:/ > while [ "$status" !~ exit ] > if [ ! -e ctdltabl.sys ] > configur x > status=$? crash=kablooey > if [ $status !~ 0 ] ; status=exit; fi > else > status=0 > fi > if [ $status ~ 0 ] > citadel +netlog $crash > status=$? > # echo citadel returns status = $status > if [ $status ~ 1 ] ; cp -f *.sys backup; fi # timeout > if [ $status ~ 0 ] ; status=exit ; fi # sysop exit > if [ $status ~ 3 ] ; status=exit ; fi # remote exit > if [ $status ~ 10 ]; uucall ; fi # uucp event > fi > unset crash > done > unset status # in case we sourc'ed this file.... > cd $here And here is an example of a MS-DOS command.com batch file that does essentially the same thing: > echo off > > :reset > configur + > if errorlevel goto byeo > goto loop > > :loop > citadel +ymodem > if errorlevel 20 goto popular > if errorlevel 6 goto callbix > if errorlevel 3 goto loop > if errorlevel 3 goto timeout > goto byeo > > :popular > tm >> timelog > echo popular >> timelog > popular -msb > c:\hfh\library\popular > netmap -p > c:\hfh\library\netmap > callstat -s -u > goto loop > > :callbix > tm >> timelog > echo callbix >> timelog > bixcall -x > goto loop > > :calluucp > tm >> timelog > echo calluucp >> timelog > uucall -suucp -x > goto loop > > :timeout > tm >> timelog > echo timeout >> timelog > > :byeo 8) AUDITING THE USERS STadel isn't really set up to be properly paranoid about users, but it makes a few attempts to track user activity. If you want, you can log user logins/logouts, file download activity (file uploads are already logged as messages in the room that the files are uploaded into), and, with the use of some external programs, make up reams of silly data on call frequency, etc. The simplest form of auditing is the call-log. If you #define CALL-LOG (in ctdlcnfg.sys) as nonzero, STadel will create the file calllog.sys in your auditdir. This file consists of records of the following form: System brought up 88Oct29 @ 22:31 orc : 88Oct29 22:38 - 22:39 (console) P fred q. pirate : 88Oct29 22:58 - 22:59 (1200) + - sam the novice : 88Oct29 23:12 - 23:50 (2400) + System brought down 88Oct29 @ 22:59 These either tell you that the system was brought up or down at a certain time, or the times that a user was on the system, what baudrate s/he was calling the system at (`(console) is, of course, someone at the system console), whether or not s/he was a new user, and how s/he exited the system. The funny letters at the end of a line tell the story; here they are: ` ' - .terminate quit `a' - .terminate punt `-' - .terminate stay `g' - Console user kicked off when carrier was detected. (this happens if you're on console and you ^Lm instead of .tq) `d' - Lost carrier. `p' - Punted by preemptive event and/or network mode. `E' - punted because of excessive line noise. `t' - Timed out. `P' - Punted by network polling (^LNP or ^Lm on a console user.) `k' - User killed by ^Lk `+' - New user. You can further customise the auditing by using other commands in ctdlcnfg.sys; If you #define FILE-LOG, STadel will keep track of all files downloaded from your system in the file filelog.sys in your #auditdir. The information it keeps in that file is the user who downloaded, what time s/he started downloading it, the room, and the file that was grabbed. If you don't want as much info in calllog.sys, you can tell citadel to either log calls or system exits by #defining AUDIT-CALLS or AUDIT-EXITS.